Enterprise engineering systems, sometimes also referred to as spatial information management (SIM) systems, are computer-aided design (CAD) systems that facilitate 2D and 3D modeling and visualization. These systems are used in the design, construction, operation and modification of industrial plants, such as oil refineries and power generating stations, as well as other large, complex structures, such as high-rise buildings, ships, and mining and other materials handling facilities. With their graphical user interfaces (GUIs), enterprise engineering systems enable designers to lay out structural, piping, electrical, heating, ventilating and air conditioning (HVAC) and other complex systems and to visualize all or selected portions of a project at various stages of construction or operation.
Most modern enterprise engineering systems utilize object-oriented paradigms, in which software constructs called “objects” represent real-world items, such as beams, walls, floors, pipes, valves, conduits, switches, fans, ducts and the like. Objects are typically implemented in software as data structures (ordered groups of data elements) that store information identifying the type of a real-world items represented, as well as information (such as length, width, color, capacity, etc., as appropriate for the item represented) about the specific item represented by each object.
Most objects are related to other objects. For example, if a pipe is to be attached to a beam, the object that represents the pipe is related to the corresponding beam object. Relationships are also typically represented by data structures. For example, the relationship between the pipe object and the beam object may include information that identifies the physical attachment of the pipe to the beam. Furthermore the relationship may include information indicating that the beam supports the pipe, and not the other way around.
Relationships between objects are ordered concepts. A relationship may indicate a logical order in which objects are added to a model. For example, when modeling a power plant building, a designer typically adds columns and places the columns at desired coordinates, and then the designer creates footings under the columns. The footing objects are related to the column object such that, for example, if a column is later moved or the weight it must bear changes, the enterprise engineering systems automatically moves the footing or automatically changes its size as required to bear the new weight.
In this example, the beam object and the footing object have a parent-child relationship. Here, the beam is referred to as a “parent” of the footing object, and the footing is referred to as a “child” of the beam object, because characteristics of the footing depend on characteristics of the beam. The characteristics of the footing, as well as characteristics of any other objects that are children of the beam, are automatically recalculated by the enterprise engineering system whenever a characteristic of the beam changes.
Many objects are made up of other objects. For example, a boiler may include a burner, a series of pipes and a pump for forcing fluid through the pipes. In this case, separate objects represent the boiler, the burner, the pipes and the pump, and relationships between the boiler object and the other objects indicate that the boiler includes or is made up of the other items and that the other items are parts of the boiler. Data structures that represent relationships between objects may include pointers or references to the corresponding object data structures.
Many modern enterprise engineering systems utilize relational databases (RDBs) or other database management systems (DBMSs) to store objects and relationships among the objects. In these systems, RDB records may be used to store the object and relationship data structures.
One particularly useful feature of enterprise engineering systems is the ability to copy one or more objects in a model, along with their corresponding relationships, and paste the copies into another portion of the model or into another model. For example, in a multistory office building model, objects and relationships representing plumbing of a given floor may be copied and pasted into other floors. A copy operation includes creating copies of the data structures that represent the objects and relationships being copied. A copy operation also adjusts values in the newly created data structures, such as to give the newly created objects unique identifiers and to establish relationships between the new objects and the portion of the model (such as the floor) where the objects are being pasted.
In order to maintain the validity of objects and relationships in a model's database, a copy operation should be “atomic.” That is, either the entire copy operation should be completed without error, including storing (“committing”) the newly created objects in the database, or none of the copy operation should be performed and no new objects should be stored in the database. If a non-atomic copy operation were to be abnormally terminated, such as by a system failure (“crash”) or an attempt to copy a corrupt data structure, the copy operation would be only partially completed, and some parent objects or parent-child relationships might be missing from the resulting model, which would seriously undermine the value of the model. A database with missing objects or relationships is referred to as being “invalid” or “inconsistent.”
Thus, to ensure atomicity, enterprise engineering systems perform copy operations in three steps. In the first step, all the data structures representing the objects and relationships that are to be copied are brought into memory and data structures representing all the newly created objects are created in memory. Then, in the second step, all the needed value adjustments in the newly created data structures are performed while the data structures are still in memory. The second step includes establishing all the relationships among the newly created objects and between the newly created objects and the existing objects. Then in the third step, the newly created data structures representing the new objects and relationships are committed to the database. Thus, the database reflects the model either before any of the copy operation has been performed or after the entire copy operation has been completed, but not at any intermediate stage. Atomic operations are also referred to as “transactions.”
Many industrial plant models involve very large numbers of objects and relationships, which pose problems for enterprise engineering systems. Copying such a large number of objects and their relationships may exceed the memory capacities of these systems. As noted, a system's memory must be large enough to store all the data structures representing the objects and relationships that are to be copied, as well as the copies of these data structures. Even if a system has sufficient memory for a given copy operation, copying a large number of objects and relationships can take a significant amount of time, sometimes several hours. A long copy operation that abnormally terminates must be “rolled back” to undo the partial copy, and then the copy operation may be restarted from the beginning, all of which wastes valuable user and computer time.